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ABSTRACT 



A software -based computer security enhancing process and 
graphical software-authenticity method, and a method to 
apply aspects of the two are disclosed. The process provides 
protection against certain attacks on executable software by 
persons or other software used on the computer. Software 
using this process is protected against eavesdropping (the 
monitoring of software, applications, the operating system, 
disks, keyboard, or other devices to record (steal) 
identification, authentication or sensitive data such as 
passwords, User-ID's, credit-card numbers and expiry dates, 
bank account and PIN numbers, smart-card data, biometric 
information (for example: the data comprising a retina or 
fingerprint scan), or encryption keys), local and remote 
tampering (altering software to remove, disable, or compro- 
mise security features of the altered software) examination 
(viewing the executable program, usually with the intent of 
devising security attacks upon it), tracing (observing the 
operating of an executable program step-by-step), and 
spoofing (substituting counterfeit software to emulate the 
interface of authentic software in order to subvert security) 
by rogues (eg: Trojan Horses, Hackers, Viruses, Terminate - 
and-stay-resident programs, co-resident software, multi- 
threaded operating system processes, Worms, Spoof 
programs, key -press password capturers, macro recorders, 
sniffers, and other software or subversions). Aspects include 
executable encryption, obfuscation, anti-tracing, anti-tamper 
& self -verification, runtime self-monitoring, and audiovisual 
authentication (math, encryption, and graphics based 
method permitting users to immediately recognise the 
authenticity and integrity of software). FIG. 5 in the speci- 
fication depicts the many components and their interaction. 

21 Claims, 6 Drawing Sheets 
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COMPUTER SOFTWARE 
AUTHENTICATION, PROTECTION, AND 
SECURITY SYSTEM 

This is a continuation of application Ser. No. 08/679,077, 
filed Jul. 12, 1996. 

BACKGROUND OF THE INVENTION 

The present invention relates to a computer program 
having enhanced security features, and also to a system and 
method for enhancing the security features of a computer 
program. In particular, the present invention relates to such 
a program, and the system and method for creating the 
program, having increased security features to prevent ID 
data (as defined) eavesdropping and/or theft and/or ensure 
authenticity. 

Description of the Prior Art 

Computers are becoming widely interconnected and 
heavily relied upon to process and store sensitive informa- 
tion. The risk of unauthorised access to computers and 
information has increased with this increased interconnec- 
tivity. 

Many security advances exist in the areas of identification 
& authentication of users, cryptography, virus prevention, 
and the like, however — almost all of these advances ulti- 
mately rely upon computer software. Most computer sys- 
tems are, or are accessed by, small personal computers, and 
most software used on these personal computers is suscep- 
tible to "local attacks" — attacks which are mounted from 
inside said personal computers against said software by 
other software or people. 

Passwords, User-ID's, credit-card numbers and expiry 
dates, bank account and PIN numbers, smart-card data, 
biometric information (for example: the data comprising a 
retina or fingerprint scan), cryptographic keys, and the like, 
are all examples of identification, authentication or similar 
data which is either sensitive in itself, or may allow access 
to sensitive, restricted or other information or services. 
Hereafter, the term ID-Date will be used to refer to the 
abovementioned identification, authentication or similar 
data, excluding ID-Data which is valid only for a single use, 
or which is designed to expire at regular intervals of short 
periods of time, say less than two minutes. 

Illegal access to computer system information can be 
obtained by exploiting various security flaws found in 
computer software products. A common flaw is the suscep- 
tibility of said software to the theft of ID-Data either directly 
from said software as it executes, or, from the operating 
system or hardware on which said software is executing. 
Another common flaw is the susceptibility of said software 
to (illegal) modification. Such modifications may remove, 
disable, or compromise the security features of said soft- 
ware. 

Viruses, Terminate-and stay-resident programs (TSRs), 
co-resident software, multi-threaded operating system 
processes, Trojan Horses, Worms, Hackers, Spoof programs, 
keypress password capturers, macro-recorders, sniffers, and 
the like can be effective at stealing ID -Data and are 
examples of (a) rogue software, (b) people capable of 
subverting security software, or, (c) software which can be 
configured for illegimate purposes. Hereafter, the term rogue 
software will be used to refer to software or subversions 
such as the above mentioned (a) (b) and (c), used for the 
purpose of stealing ID-Data. The definition of our term 
"rogue software" when used herein also includes software or 



)6,328 

2 

other means used to tamper with other software. The term 
tampering is defined hereafter. 

There are many ways to introduce rogue software into a 
computer system. Viruses spread automatically by introduc- 

5 ing themselves. Trojan-Horses are usually introduced by 
tricking users into allowing them to execute (such as by 
masquerading as a new or well-known computer game or 
other product). Existing security problems may be utilised to 
introduce rogue software, some well known problems 

10 include lava bugs, errors, or oversights, ineffective physical 
security (for example: permitting rogue software to be 
introduced directly on floppy disk by an intruder); electronic 
mail attachments which automatically execute or execute 
after a simple mouse-click, incorrect security settings on 
internet, world-wide-web, TCP/IP or modems, and tamper- 

15 ing (see definition hereafter) with legitimate software 
in- transit as it flows from remote internet sites into a users 
computer, to name a few. 

Rogue software, once introduced, can steal ID-Data as 

2Q mentioned hereinbefore. It may monitor keyboard (for 
example: by recording every key, as the user presses each 
one, in order to steal a password as it is being typed in), 
serial-port, mouse, screen, or other devices to steal ID-Data 
directly from them. It may monitor other software, 
applications, the operating system, or disks to steal ID-Data 
from there also. Once stolen, this ID-Data may be stored 
locally (for example: in memory or on-disk) or transmitted 
to remote locations (for example: by modem or network) or 
used immediately to perform illegal operations. Hereafter, 

3Q the term eavesdropping will be used to refer to the moni- 
toring of a computer to record ID-Data. 

For example, a key press recorder could secretly, and 
unbeknown to the computer user, record all the keys pressed 
by the user into a hidden systems file. The information 

35 recorded could include a user's password and other sensitive 
information which an organisation would obviously wish to 
protect. 

Additionally, rogue software may remove, disable, or 
compromise existing computer software security features by 

4Q modifying the memory, disk or other image of said computer 
software. Rogue software may also utilise tampering tech- 
niques to alter existing computer software in order to steal 
ID-Data from it, or may attach itself to existing computer 
software (as is the case with many computer viruses), 

45 Hereafter, the term tampering will be used to refer to the 
abovementioned modification of computer software. Tam- 
pering may take place either locally (within a users PC) or 
remotely (for example: at one of the points which a com- 
puter program passes through as it is being download). 

50 Further, counterfeit software can be substituted for legiti- 
mate software. The counterfeit will appear real to a com- 
puter user, but actually acts to subvert security, such as by 
stealing ID-Data. Sometimes called "Spoof programs or 
Trojan Horses, counterfeit software of this type may invoke 

55 the original legitimate software after having stolen ID-Data, 
so as not to arouse a user's suspicion. 

Another potential security flaw found in computer soft- 
ware products is susceptibility to examination and reverse - 
engineering. Known (but generally secret) and other security 

eo problems or mistakes can be discovered by hackers and the 
like from the examination of existing computer software and 
by tracing its operation. 

Additionally, Computer software piracy is a growing 
problem, and the existing simple means which prevent this 

65 problem (such as registration or serial numbers and 
customer-names being encoded within the product) are 
becoming less effective. 
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There is necessity within the try-before-you-buy software 
market for vendors to employ effective features which allow 
old software to expire without fear of hackers or the like 
removing said expiry features and for secure registration of 
software to be provided through the use of software unlock- 5 
codes. 

There is also need for software to be able to prevent 
security attacks upon itself (ie: tampering) and upon its own 
attack-detection code. There may also be a future need for 
software to identify the attacker for subsequent prosecution. 10 

There also exists cases where untamperable software 
usage metering may be desirable, and where effective 
password-protection of software execution may also be 
desirable. ^ 

Known advances in certain areas of computer security 
have been successful and documented. There have been 
some advances in anti-virus technology which help detect 
and prevent certain security problems. There have been 
numerous advances in hardware -assisted computer security 
add-ons and devices, such as smartcards and biometric input 
devices. There have been advances in cryptographic tech- 
niques. Generally, all of these advances require authentic, 
un-tampered-with computer software in order to work. 
There have been relatively few advances in software based ^ 
integrity self -checking (eg: tamper protection), and no prior 
software-based advances in preventing eavesdropping or the 
electronic theft of ID-Data, and no prior software-based 
advances in self-authentication. 

SUMMARY OF THE INVENTION 30 

This invention seeks to provide computer software having 
enhanced security features, to a process which substantially 
enhances the security of computer software (hereafter 
referred to as the improved process) and to a method by 35 
which to apply said improved process (hereafter referred to 
as the applicator). 

The improved process consists of including computer 
code to automatically detect tampering of said computer 
software, and computer code to prevent the theft of ID-Data 40 
by replacing existing vulnerable (to rogue software eaves- 
dropping or attack) software or operating system code with 
secure equivalents which utilise anti-spy techniques (as 
described later in this document). 

Preferably, the improved process also consists of includ- 
ing computer code to prevent decompilation, reverse- 
engineering, and disassembly by the inclusion of obfuscat- 
ing code inserts, and the use of executable encryption. 

Preferably, the improved process also consists of includ- 50 
ing code to prevent execution-tracing and debugging by the 
use of code designed to detect and prevent these operations. 

Preferably, the improved process consists of, or also 
includes, human-recognisable audio-visual components 
which permit the authenticity of said computer software to 55 
be easily verified by the user on each invocation using 
techniques described later in this document. 

The idea which lead to the creation of this invention can 
be summarised as follows: If a piece of computer software 
that is executing can be shown to be the genuine article, and 60 
this software can protect itself against eavesdropping, and 
this software can prevent tampering of itself, then is it 
possible for this software to function in a secure manner, 
even within an insecure operating system. This invention 
permits the creation of such a piece of computer software — 65 
having a tangible, useful security advantage and hence 
improving its value. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention will become more fully understood 
from the following detailed description of preferred but 
non-limiting embodiments thereof, described in connection 
with the accompanying drawings, wherein: 

FIG. 1 illustrates the standard operation of a computer 
system known in the prior art; 

FIG. 2 illustrates the known operation of a rogue or 
"spoof program; 

FIG. 3 illustrates application code updated with the pre- 
ferred embodiment; 

FIG. 4 illustrates the known operation of a rogue eaves- 
dropping program; 

FIG. 5 illustrates the interaction of the components of the 
updated application; 

FIG. 6 illustrates the general structure of the preferred 
embodiment of the applicator; 

FIG. 7 illustrates a standard layout for a program to be 
executed on a computer system; 

FIG. 8 illustrates the standard layout of an EXE header 
under the MS-DOS operating system. 

FIG. 9 illustrates a standard layout of an EXE program 
under MS-DOS; 

FIG. 10 illustrates an altered executable form constructed 
in accordance with the specific embodiment; 

FIG. 11 illustrates a first stage of execution of the new.exe 
executable; 

FIG. 12 illustrates a second stage of execution of the 
new.exe executable file; and, 

FIG. 13 illustrates a third stage of execution of the 
new.exe executable file. 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS 

Throughout the drawings, like numerals will be used to 
identify similar features, except where expressly otherwise 
indicated. 

As will be described hereinafter, the present invention has 
general applicability to many different operating systems 
including MICROSOFT DOS*™ (Microsoft Disk Operating 
System) APPLE MACINTOSH OPERATING SYSTEM, 
UNIX™, etc. 

Detailed hereafter are several security-enhancing tech- 
niques to combat eavesdropping. Security is provided by (a) 
hampering examination of software -code operating system 
code or or parts thereof through the use of the encryption or 
partial encryption of said code, (b) preventing the disassem- 
bly of said code through the inclusion of dummy instructions 
and prefixes and additional code to mislead and hamper 
disassembly (ie: obfuscating inserts), (c) preventing the 
computerised tracing of the execution of said code (for 
example: with code debugging tools) through the use of 
instructions to detect, mislead, and hamper tracing, (d) 
preventing tampering of said code through the use of scan- 
ning to locate alterations, either or both on-disk and in 
memory either once at the start of execution, or continuously 
upon certain events, or (e) preventing ID-Data theft through 
the inclusion of secure input/output routines (for example: 
routines to bypass the standard operating system keyboard 
calls and use custom -written higher-security routines as a 
replacement) to replace insecure computer-system routines. 
Hereafter, the term anti-spy will be used to refer to any 
combination of one or more of the abovementioned tech- 
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niques [(a) through (e) or parts thereof] used to prevent manual and automatic disassembly nearly impossible, since 

eavesdropping. the decryption should be designed to fail if tampering or 

Referring now to FIG. 1 there is illustrated the standard tracing is detected, 
scenario for "running" a given executable program 16, under 

the control of a computer operating system 17 on a computer 5 Aspect 3. Detecting Tampering 

18. In the preferred embodiment of the present invention, the M hereinbefore described, it is desirable to detect 

executable program 16 is subjected to modification, as will tampering, since this may lead to the reduction of software 

be described hereinafter, to- ensure its integrity and improve security 

its security. There are five aspects of this inventions ™ . , , iL c , .... 

j ... L -j • u * *• ii m fnis can °e achieved with the use or code which is 
improved process, although said provess is still substantially 30 A A , r ,. L1 , ... , , r 
. . * n r.i. 4 tl / protected trom disassembly and exam ination through obrus- 
lra proved even if not all of them are present. These aspects , 4 . J ... , . & , 
/nn . . -t- cation and encryption, which re-reads its own external- 
are: (1) Preventing eavesdropping (2) preventing disassem- . , , 

■ 1 j . « *4* 4 • /,.\ image and compares it with its known memory image or 

bly and examination (3) detecting tampering (4) preventing & . . t , f , 4 A , 4 4 . 4 ... 

^ , , /*-\ . /l 4- -4 precalculated check-data to detect hot-patchine fie. the 

execution-tracing and (5) ensuring authenticity. r - .. - .f , , to \ , , 

to w to ' 1S modification of software sometime after it has been loaded 

Preferred embodiments illustrates each of these aspects of from disk> but (usually ) beforc execution of the modified 

the present invention will now be described. &ection has commenced). 

Aspect 1. Preventing Eavesdropping Additionally, the software can scan the memory image of 

itself one or more times, or continuously, to ensure that 
As hereinbefore described, it is desirable to prevent rogue 20 unexpected alterations do not occur, 
software from eavesdropping on ID-Date. By replacing Certain modifications to the external copy of software are 
software which is vulnerable to eavesdropping with equiva- reflected in subtle changes to the environment in which the 
lent software which is far more secure, this purpose is modified software will be executed (for example: the size of 
achieved. To remove the vulnerability from the secure the code, if altered, will be reflected in the initial code size - 
equivalent software, replacement routines may communi- 25 value supplied to the executing program being incorrect.), 
cate directly with the hardware of the computer (for Additionally, certain modification to the operating system 
example, they may communicate with the keyboard circuitry and environment of said software can also be monitored (for 
instead of using the system-supplied (and hence possibly example: certain interrupt vector table pointers in Intel- 
insecure) application interface keyboard-entry function- processor applications) to detect unexpected changes by 
calls.) while disabling system interrupts which would permit 30 rogue software. These changes can also be detected to 
rogue software to eavesdrop. Said replacement routines are prevent tampering. 

coded to store ID-Data retrieved in a secure manner. ID-Data Qnce t ring fe detected) flow-of-control 

is not stored in full m plaintext (le: unencrypted) in system needs (o be changed ^ mat ^ compromise 

or application buffers. associated with ID-Data theft is avoided. This may be the 

A 4 o n 4 * t*\ * ui jr • «■ 35 security-enhanced program terminating with a message indi- 

Aspect 2. Preventing Disassembly and Examination . ; u • *. • . u u ■ j u * - « * 

r & / eating that its integrity has been compromised before all of 

As hereinbefore described, it is desirable to hamper the ID Data is entered. Alternatively, the fact that tampering 

disassembly (or de-compilation or reverse engineering) to has been detected may be kept secret and the ID -Data 

protect software against eavesdropping and tampering, and retrieved, however, immediately upon retrieval, the ID-Data 

to hinder examination of said software which might lead to 40 entered can be invalidated thus preventing access to that 

secret security problems or mistakes being disclosed. which the now potentially compromised ID-Data would 

. ■ Obfuscating inserts can successfully prevent automatic have otherwise allowed. This latter method allows for the 

disassembly. Obfuscation is achieved by following uncon- possibility of security-enhanced software informing remote 

ditional jump instructions (for example, Intel JMP or CLC/ or other authorities that tampering was detected and possibly 

JNC combination or CALL (without a return expected) or 45 other information, such as what specifically was altered and 

any flow-of-control altering instruction (which is known not °Y whom. Care must be taken to ensure the integrity of the 

to return to the usual place) with one or more dummy "remote-informing" code before ID-Data entry is permitted. 

op -code bytes which will cause subsequent op-codes to be 

erroneously disassembled (for example, the Intel OxEA 5Q ^pcci 4 Preventing Execution-Tracing 
prefix will cause disassembly of the subsequent 4 op-codes Apart from "spoofing" (described in aspect 5 hereafter) 
to be incorrect, displaying them as the offset to the JMP the last resort of a rogue who is prevented from disassembly, 
instruction ' indicated by the OxEA prefix instead of the tampering, and eavesdropping on software is to trace the 
instructions they actually represent). execution of said software in order to facilitate the compro- 
Dummy instructions may also be included to hamper 55 mise of its security. Hampering tracing (tracing, is some- 
disassembly by deliberately misleading a disassembler into times called debugging) prevents this, 
believing a particular flow of control will occur, when in fact There are numerous methods of detecting a debug- 
it will not. environment (ie: when tracing is taking place). When corn- 
Row of control can be designed to occur based upon CPU bined with decryption and tamper-protection as hereinbefore 
flag values determined from instructions executed a long 50 described, it makes the rogues task of detecting and bypass- 
time ago. Together with tracing preventing, this makes ing debug-detection extremely difficult. Reference and 
manual disassembly nearly impossible. examples to Intel and MS-DOS environments follow 
The majority of the executable portions of the software hereafter, although it will be apparent to one skilled in the art 
can be encrypted for external storage. The decryption taking that these and similar methods are applicable on other 
place in-memory after the software is loaded from external 65 platforms. 

sources, under the control of a decryption "header" which Standard Intel x86 interrupts 1 and 3 are used by debug - 

prevents its own tampering and disassembly etc. This makes gers to facilitate code tracing. By utilising these interrupts 
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(which are not normally used by normal applications) in which executes during system interrupts or after the parent 

security-enhanced software, it hampers debugging, since process has terminated will again hamper tracing, 

built-in debugging functions are now not automatically Bypassing system routines (eg: in DOS, using direct 

available. memory writes instead of DOS system calls to revector 

Monitoring the system timer to determine if software 5 interrupts) will further hamper debugging and rogue soft- 
execution has spent too long accomplishing certain tasks can ware monitoring, as will unravelling loop constructs (which 
detect a situation where code tracing has been in effect and will make tracing long and cumbersome). Code checksums 
a breakpoint was reached. and operating-system checks (eg: interrupt table pointers) 

Disabling the keyboard will hamper debuggers, since can be designed to detect debug-breakpoint instruction 
tracing instructions are usually issued from the keyboard. 10 inserts or other modifications. Using the result of the check- 
Similarly, disabling other places from where tracing instruc- sum f °r some obscure purpose (eg: decryption, or (much 
tions are usually issued (eg: serial ports, printer ports, and laler ) control-flow changes) will further hamper tracing, 
mouse) or displayed (eg: screen) will also hamper tracing. It will be apparent to one skilled in the art of low-level 

System interrupts can be re -vectored for use within the software programming that a combination of techniques to 

secure software to perform tasks not usually performed by 15 detect, prevent, and mislead tracing will provide a mecha- 

those interrupts. Debuggers usually rely upon system inter- making tracing very difficult, if not impossible. At the 

rupts also, so to do this would usually disable or destroy a verv least > * l w iU require an expert with very expensive tools 

debugger being used to trace the software. Disabling inter- a °d perhaps some understanding of the original software 

rupts and performing timing-sensitive instructions between design a very long time to make any debugging progress— a 

them will further hamper debugging. When tracing software, 20 situation which is recognised in military software security 

instructions are usually executed one-at-a-time in order for accrediation worldwide as highly desirable, 

the user to understand their operation. Many system inter- Aspect 5 Ensuring Authenticity 

rupts must occur regularly (eg: timer and memory re-fresh , , . , . 

operations), so debuggers usually do not disable interrupts k ln l™*™* ™* » «P«* ° f th ° P resent "venhon 

even when they encounter an interrupt-disabling instruction. 25 hfre.s provided a method of providing for a secure entry of 

If timers and the like are re-vectored in two separate stages, ' D " I ? ata in a ^"p>iter system comprising ^activating a visual 

any timer (etc) interrupt occurring in between the two stages ^f'f or ™™!"»> "d/or audio feedback (hereinafter 

will fail, and usually crash the computer. Further, interrupts ca led an '^to/visual component) as part of said secure 

can be disabled or enabled using obscure means (with en ^ of W ' Da * f a * 10 hamper emulatI0n ° f sa ' d <* cure 

flag-altering instructions for example) to hamper tracing. 30 entI ? P rocess ' Pr f ef f ra " y ' ' he amma,10n mcl " de f s fe °? ba <; k 

* , 4 4 - iL . t c jt t_ i -j 1 1 i 7 portions as part of the ID -Data entry process. Preferably, the 

Discretely testing the status of disabled or enabled system . . , , , . it , ' 

c ... . ( . ..t_ j . animation is repeatable and vaned in accordance with the 

tacihties (eg. interrupts, keyboard, vector-pointers) to ensure . c t , c ,. 

. , v & . , . i . ,t information entered. The animation preferably comprises 

that a debug environment has not altered or by-passed them - fn . , . , , . £ 

.„ ■ • 1 l -1 2.5D or 3D animation and includes animation of any 

will seriously hamper tracing also. ^ ^ D&ia. in ut 

Certain computer processors have instruction caches. In n c U1 _, 4 4 tU 

r \ . • Preferably, the animation is designed to tax the computer 

some circumstances, it is possible to alter the instructions , , , f. r r c 

. , , ' £ mr t tU , t #u resources utilised and thereby making any forgery thereof 

immediately before the CPU encounters them, but the mQre ^jg^^ 

altered instruction will not be executed normally because the , , . , ^ . * 
cache copy has the "old" one still. In debug environments, „ t l wlU be a PP arent t0 ° n l sk ' lled in the art °fJ° W J Icv P l 
the cache is usually flushed, so any altered instructions will 40 software Prop«nming that the five aspects described herein 
actually be executed. This again hampers tracing. ' ^ bc combined to provide substantially stronger scanty 
Tr . * . . . . t^t-c «/r> , l »an any aspect taken on its own. For instance, to combine 
Using strong cryptographic schemes such as DES (Data . \ t r t . ... , , . , , , 
c ?• of a a\» ncA ../nnnrcT CUA w ro tamper-detection with encryption, the precalculated check- 
Encryption Standard) , or RSA (RIVEST, SHAMIR, , . , . , , . . j \ *• j it 
*^r.Tx^*xT ai .1 \ » ,-, „ . data as derived during tamper-detection described herein- 
ADELMAN, Algorithm) or the like will present the AS - . f „ . i, . , ftU 4 . , . 

. . - r 45 before may actually be one part of the decryption-key which 

examination of any decrypuon routines from revealing a ^ ^ , o succ6SsM d , rem ^f ni ex 4 ulable 

simple patch to disable said rouUnes. When tracing software, software , f rev6ntion . of . tracing and environment charac- 

the program stack is usually used by the debugger either . . /■ i j- j u a * »■ j *u j 

. s °_ t 1 . J . „f. & . tenstics (including debugger detection as described 

during the tracing operauons or a. oUier times. This B easily hereafler) \ K ^ of sM ^ & . 

detected and by using the area of the stack which will be 50 makes ^ determination of said decry pti 0 n-key by any. 

destroyed by unexpected stack -use for code or cntical data, . 4 , J K J ■ , 

r J .. . * , c , • person or computer program other than the secure original 

software can be designed to self-destruct in tlus situation. an extremely difficul ^ ;f not impossible> task . 

Scanning the command environment and the execution ^ „ , , . f , .„ , . r 

.^j^^. . rc , . Further, it will also be apparent to one skilled in the art of 

instruction can detect the execution of software by unusual , , * u *u * i . 

o i_- r unrnn/,,, • .i j i- low-level sottware programming that a simple construct 

means. Searching lor DEBUG in the command line, or « . 1XTir , u ~ a c * i c* 

& _ , , . r . -.1 such as a JNE to alter program now-of-control after tam- 

scanning memory for known debuggers for example will . , , j * ; j - ca • * • iL am 

to . A . • . penng has been detected is insufficient, since the JNE 

detect tracing. Additional, by detecting which operating r rt t t lf . , ■ . . tn ™ , 4 . 

. ... , * ,i * i r .i & ^ , construct itself is subject to tampering. The decryption 

system process initiated the load of the software, unexpected , , , . . f . f r. . it _ y . 

J x i j , i j process described hereinbefore is preferable since there is no 

processes (eg: debuggers) can be detected. sjngle point of ^ caQ pQssibly a tampered 

Monitoring system buffers (eg: the key board memory 6 o executable that would execute. Indeed, the executable pro- 
buffer) or hardware (eg: the keyboard circuitry and internal tcctcd with cncryption wiI1 not evcn be transformc d into its 
buffers) for unexpected use (eg: keyboard input and pro- intcndcd form if tampering ^ detected, 
cessing is occurring when the software is not requesting it) 

will also detect debuggers, which usually rely in part on GENERAL DESCRIPTION OF PREFERRED 

system functions in order to operate. 65 EMBODIMENT^) 

Building a process or multiple processes which are tra- Notwithstanding any other forms which may fall within 

ditionally difEcu It to trace, such as a resident or child process the scope of the present invention, preferred forms of the 
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invention will now be described, by way of example only, Firstly, the executable portion of the secured ID-Data 

with references to the accompanying drawings. entry code can be protected against tracing, disassembly, 

In the preferred embodiment of the present invention the tampering viewing, reverse engineering keyboard entry 

user interface for the acquiring of ID-Data is secured theft, eavesdropping, hot patching and other attacks by 

whereby the duplication of the interface is rendered math- 5 transforming the secured ID-Data entry program code 31 

ematically complex such that cipher-code breaking tech- from its normal executable form 16 (FIG. 2) to a corre- 

niques are required to produce a counterfeit look-alike sponding secured form of executable (as hereinbefore 

interface. By making the authentication interface (ie: described— refer aspects 1 to 4). These techniques are 

ID-Data entry screen— for example: a logon screen or a prc ferably applied to the application code 16 in general or 

screen for entering credit card details) unable to be 1Q lcss prcfcrably specifica n y limitcd to the i D . Data cntry 

emulated, tampered with, or reversed engineered, the appli- rtr , rt ,v,« c id tv^r^f 

1t - , . , , c , A . pur nuns incrcoi. 

cation program allows for a higher degree of security and r 

authenticity even in insecure environments such as the Additionally, the secure ID-Data entry program code 31 is 

Internet or home software applications. Referring now to llself created. This code 31 preferably comprises a complex 

FIG. 2, there is illustrated a classic form of rogue attack on graphical user interface series of screens and animation 

a computer system. In this form of rogue attack, a rogue's 15 designed to make duplication by a rogue thereof extremely 

"spoof 1 program 22 is inserted between application software difficult. 

16 and the user 23. The application 16 normally has a Initially, the complex user interface should include facili- 

portion 24 devoted to ID-Data entry and verification or the ties to disable any frame buffer recording devices, the 

entry of commercially sensitive information (including pass- disablement occurring before each frame is displayed. Also, 

words etc) to the application in addition to the application 20 whefe a mTllti . tasking opening system is in use, or where 

code 25. The spoof program 22 is designed to exactly reflect context switching is enabled( swi^g out of the interface 

the presented user interface of ID-Data entry code 24 to the screen is ferabl disablcd or Ir>Data ent procedures 

user. The user 23 is then fooled into utilising the masquer- . , r . . . , , . . e 

ading spoof program 22 as if it was the application 16. encr ^ d « temiinatcd when the interface screen is 

Hence the user can be tricked into divulging secret infer- 25 ? wa £ p f d 0Ut ' ^ imagCS preScntcd whl ' h fo f? part of f hc 

mation to the spoof program 22. An example may include a ID ' Data c fl greens comprise complex 3D animation 

classic "login spoof' wherein the spoof program 22 prints sequences having a high degree of complexity and extensive 

the login prompt (ie: ID-Data entry) message on the screen usc of screcn colours and smGn resolution in addition to 

and the user mistakes the login prompt for a legitimate one, v ^ ual 50 ™ to make copying thereof extremely 

supplying a user name and password to this program 22 30 difficult. 

which records this information as well as passing it on to the The complex computer graphics can be created utilising 

login code 24 of application 15 so as not to arouse the standard techniques. For information on how to create 

suspicion of user 23 — or by issuing a message, such as complex 3D imagery, reference is made to "Compare 

"incorrect password, please try again" and then passing Graphics, Principles and Practice" by Foley, Van Dam et al, 

control to the login code 24 of application 16. 35 published 1990 by Addison-Wesley Publishing Company or 

Referring now to FIG. 4, there is illustrated a relatively olher standard textbooks on generation of computer graph- 
new form of rogue attack 40. This form of attach proceeds ics - Reference is also made to the numerous internet news 
similarity to the spoof attack of FIG. 2, with the following g^P 5 and archives on graphics and games programming, 
difference. Instead of a spoof program 22, a rogue program specifically to: com. graphics. research, 
41 is inserted which secretly eavesdrops on ID-Data entry 40 com. graphics. rendering, comp, graphics. raytracing, 
code 24, or on application code 25, or on operating system comp.graphics.misc, comp.graphics.digesl, comp.graphics 
17, or on hardware 18 or elsewhere in order to steal sensitive animation, comp.graphics.algorithms, comp.graphics, alt- 
information directly from the legitimate application. Since graphics pixutils, alt.graphics, rec.games.programmer, 
the legitimate application is still actually executing, the comp.sys.programmer, comp. sys.ibm. programmer, 
users suspicion is not aroused, since rogue program 41 is 45 comp.sys.ibm.pc.programmer, comp.os.msdos.programmer, 
generally invisible to the user 23. Alternatively, executable comp.msdos.programmer, alt.msdos.programmer. Refer- 
program 16 may have been tampered with (as hereinbefore ence is also made to "PC Games Programmers Frequently 
described) to reduce its security, alleviating the necessity for Asked Questions" document available on the internet, via 
the presence of rogue program 41. rec.games.programmer and elsewhere. 

In FIG. 5, there is illustrated in detail the structure of an 50 By encoding a complex 3D image which forms part of the 

application 50 constructed in accordance with the preferred ID-Data entry screens, the hurdle requirement of a rogue to 

embodiment running on computer hardware 18. FIG. 5 is reverse engineer the complex imagery is substantially 

similar to FIG. 4 with the important difference that user 23 increased. The inclusion of graphical animation is advanta- 

now communicates directly with secure drivers 51 which are geous in preventing static screen shot duplication attacks by 

part of the secure ID -Data entry program code 31 which is ss a rogue form succeeding. 

utilised by the security-enhance (eg. tamper protected) As noted above, it is preferable that traditionally difficult 
application code 52. It can be seen that the user 23 no longer graphical programming techniques are employed wherever 
communicates with the operating system 17 or the unpro- possible, with the aim of making it more detectable for a user 
tected computer hardware 18, thus the rogue program 41 can interacting with the system to discern lesser copies of the 
no longer eavesdrop on ID-Data. eo animation. Suitable 3D animation can include the introduc- 
In FIG. 3, there is illustrated, in more general terms than tion of shadows, the lighting of pseudo-3D animated objects, 
FIG. 5, the structure of an application 30 constructed in transparent or translucent objects, shing, reflective, or mir- 
accordance with the preferred embodiment wherein secure rored objects, gravitational effects in animated objects, 
ID-Data entry program code 31 is provided which is single-image- random -dot-stereo gram bitmaps or backdrops, 
extremely difficult to replicate, eavesdrop upon or subvert. 65 translucent threads, effects such as diffraction patterns, 
The secured ID-Data entry program code 31 can be created, screen masks, backdrops, colour palette "animation", corn- 
utilising a number of different techniques. plex animated objects resistant to simple hidden -surface 
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removal techniques known to those skilled in the art and appear on-screen when entered (eg: a password), since the 

directed to hindering duplication. display of a corresponding object would give a rogue 

Further, the animation can take into account: information on which to base guesses of the secret ID-Data. 

1. Thwarting attempts at compression of the ID-Data By utilising cryptography or having complex formulas to 
entry screens. This can be achieved by having animation 5 determine the sequencing of animation, the rogue program- 
which has low visual entropy and having many graphical mm g tbe corresponding spoof program shall have to crack 
elements which are altered from frame to frame in a manner the cryptographic scheme in order to get the selection of 
which is highly discernible to the human viewer. Apart from character animation correct for any generalized attack. In the 
being difficult to replicate, complex 3D computer imagery abovementioned example, a rogue will have to determine 
having low entropy or redundancy will require larger 10 the algorithm for producing the face, since human beings are 
amounts of storage space for a rogue attempt at duplication adept at recognising faces, and will immediately notice if the 
based on recording the screen output and therefore be more face displayed on the screen is incorrect. Such a technique 
readily discernible to the user should this form of attack be allows for a mathematically secure, visual method to guar- 
mounted. antee the authenticity of the software which generates the 

2. Hie animation is further preferably designed to thwart 15 screen ^back. The user of the software is instructed to 
a successful replay attach which is based on providing only ° ole own particular animation sequence and to imme- 
a subset (limited number of frames) of the screen animation d u iatel y discontinuing utilisation of the application 30 should 
to a viewer. This can be achieved, for example, by the thal whence ever change. The user may also be instructed 
inclusion of several animated spheres which "bounce" m to contact a tmsted person such as the supplier or operator 
around the screen and change colours in a manner that is 20 ° f lhe application to confirm that the animation sequence 
recognisable to the viewing user but which is not readily the y Wltness 15 lhe authentic sequence intended by said 
repeatable. A replay of only a subset of the screen anima- supplier. 

tions to the viewer will be highly evident in this case when, Further, the particular animation presented for a particular 

upon looping the user is alerted to a problem when the application 30 can be further customised for each applica- 

animation "skips" or "jumps" and does not operate in a 2 lion so as to be distinct (such as by the incorporation of the 

previously smooth manner. This makes it difficult for a applications name as part of the animated image), 

rogue spoof program to copy the animation without includ- Further hindrance for a rogue programmer can be created 

ing all parts of it, by hand coding portions of the animation in assembly 

3. Most importantly, the graphics presented can be cust- 30 language so as to generate the maximum possible complex- 
omised to the input data entered. For example, the informa- ity and interaction in the animation with the highest level of 
tion entered by a user can be rendered and/or animated by detail for individual workstation computers. This further 
the secure ID-Data entry program code 31 (FIG. 3). As an raises a hurdle allowing for the easier detection of rogue 
example, in an ID-Data entry program, when a user types in spoof programs 22 which will often be written in a more 
their user name, the animation can be created letter by letter. 35 convenient, higher level language (such as C or C++) which 
For example, when typing in the user name "CHRIS" each will also operate at a different speed, the user being 
letter could be rendered differently depending on those instructed to look for speed differences. 

characters previously typed. For example, the letter "I" Further, animated scene timing can be utilised, providing 
might appear as a large "barbers-pole" which spirals and anti-loop ing and frame removal detection is still catered for. 
changes colour, speed, size, and/or position and is slightly ^ The animated scene timing allows for a user to detect 
transparent, thereby allowing the animated seen which is a unexpected irregularities in a frequently presented animated 
backdrop to the character to be discerned through the interface. By including in the animation some deliberate 
character itself. For example, in the above example, the regularity (such as the rhythmic convergence of some parts 
letter "I" would only appear as the specific animated barbers of the animation in one particular spot), a rogue program- 
pole that is does if the previous letters entered were "C", 45 ming a spoof program shall also have to duplicate the 
"H", and "R" respectively. preferably complex timing events necessary to accomplish 
The utilisation of a unique sequence of animation based this convergence. The regular nature of the scene timing 
on a user's input of informatipn sensitive data increases the should be high enough so that the user expects to see certain 
difBculty of creating any "spoof program" attack on the events and thereby making it difficult for a rogue spoof 
application 30. This is especially the case since the execut- 50 program to copy the animation without including all parts of 
able code of application 30 is preferably in an encrypted it- 

form. The use of animation being particular to the order in Preferably, where possible, all ID-Data is immediately 

which characters are entered is particularly advantageous as encrypted which makes recovery of the ID -Data by a rogue 

the computational complexity of replication is substantially through analysis of the computer program memory difficult, 

increased. ss Preferably, public-key cryptographic methods (eg: Oliptic- 

A similarly effective animation technique is to produce curve, RSAor DIFFIE-HELLMAN cryptography) should be 

only one graphical object after entry of each portion of used making it impossible to reverse engineer the crypto- 

ID-Data, such as a computer-generated human's face, but graphic code to decrypt any sensitive information should it 

have the features of said face be determined by a hash or be stolen in its encrypted form. Prohibiting all or most 

cryptographic function based upon the users input. For 60 interrupts when data is to be entered and encrypting or 

example, after entry of the ID-Data "CHRIS" (in this hashing the sensitive information immediately so that it is 

example, the individual characters may not, themselves, be only stored partially, or in an encrypted form, before 

based on the abovementioned generation procedure), a teen- re-enabling interrupts is one example of achieving this 

age girl's face with long blonde hair and blue eyes may be objective. 

displayed. If the "S" was instead a "D", the face would be 65 As a further alternative, analysis of a user's personal 

entirely different. The ID-Data used for producing an object characteristics can be included as part of the interface. The 

for display should not be ID -Data which is designed not to can include attempts at recognition of a user's typing style 
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(duration of keypresses, delays between subsequent keys, computer operating system 17 (FIG. 1) for running of the 

choice of redundant keys, mouse usage characteristics, etc) executable 16. This can include relocation data, code size 

or by additional authentication techniques, including etc. The code section 72 is normally provided for storing the 

smartcards, biometric inputs such as finger prints detectors • "algorithmic" portion of the code. The data section 73 

etc. 5 normally is utilised to store the data, such as constants, or 

Further, the graphical animation routines can be "water- overlays 92 utilised by the code section 72. 

marked" by the secure ID- Data entry program code in that Turning now to FIG. 6, the preferred embodiment of an 

"hidden" information may be incorporated into the scene applicator program 60 is shown which takes as its input the 

(for example "salted-checksums") to allow careful analysis executable program 16 and performs an obfuscating step 61, 

of the output of secure ID-Data entry program code 31 to i° a ciphering step 62 and an anti-key press and authentication 

distinguish between original graphics animation and coun- step 63 (described hereafter) which perform various trans- 

terfeit animation. For example, the hidden information may formations on the executable program 16 to produce a new 

be encoded in the least -significant bit of pixel data at executable program 30. 

selected locations of the animation. The obfuscating step 61 modifies the header 71 (FIG. 7) 

The user determinable sequence of animation can also 15 of the executable 16 in addition to inserting loading code 

extend to the provided audio animation. For example, audio which will be described hereinafter. The cipher step 62 

and other feedback techniques including music and speaking encrypts the existing executable 16 and calculates check 

tones can be played in response to particular key stroke data (eg: a checksum) for the encrypted executable. The 

combinations. By utilising di fife rent voices and/or tones anti-key press and authentication step 63 replaces various 

and/or volumes and pitches for each keystroke or 20 insecure system calls with safe equivalent code and prefer- 

combination, the security of the application 30 can, once ably inserts code to graphically represent the integrity of 

again, by substantially increased. The change in voice into- said executable program. 

nation will be readily "learnt" by a user and thereby further The newly formed executable 30 (new.exe) can be then 

inhibit a rogue's ability to duplicate the same sequence of stored on disk and the applicator program 60 completed, the 

sounds or voices. Of course, the encoding of the voice 25 new executable 30 replacing the old executable program 16. 

system should be in an encrypted form. when it is desired to run the replacement executable 

Further, upon detecting any attempt to subvert the secure program 30, the replaced executable (new.exe) executes the 

ID -Data entry program code 31 (eg: subsequent to detecting obfuscating code, previously inserted by applicator 60. The 

tampering), a notification message is preferably sent to a 3o obfuscating code initially decrypts the executable program 

prosecuting body or the like where the application 30 is and validates the stored check-data before re -executing the 

currently, or later becomes connected to a network such as decrypted executable. 

the Internet, or by other means (eg: via Modem or by foregoing description of the preferred embodiment 

including coded information in public or other files). has been in general terms and it will be understood by those 

For application programs 30 requiring activation by a host 35 skilled in the art that the invention has general application to 

program executed on a different computer, a secure means of many different operating systems, including MS (Microsoft) 

activation can be incorporated into the client application 30. DOS (Disk Operating System), APPLE MACINTOSH OS 

The host and client intercommunication can issue challenge (Operating System), OS/2 (OPERATING SYSTEM 2), 

and response code authentication and verification utilising UNIX, etc. 

cryptographic systems such as public-key encryption and/or ^ The most common operating system utilised today is the 

other standard means of overcoming data replay attacks and MS-DOS (Microsoft Disk Operating System) operating sys- 

other threats designed to trick the secure client application tem. This operating system is designed to run on INTEL x86 

30 into activation. microprocessors and includes a large number of historical 

It would be appreciated by a person skilled in the art that "quirks" which give use to greater complexity than would 

the process of coding any data entry process utilising these 45 perhaps be otherwise required when designing a new oper- 

techniques, together with additional techniques to protect ating system from "search". For illustrative purposes, there 

against recording, and eavesdropping, and executable pro- will now be presented a specific embodiment of the pre- 

tection techniques may be necessary to improve the security ferred embodiment designed to operate under the MS-DOS 

of the interface. Additionally, executable encryption, addi- operating system. Unfortunately, the example is quite com- 

tional authentication, and other methods are desirable in 50 plex as it operates in the framework of the MS-DOS 

producing the protected executable. operating system. Therefore, it is assumed that the reader is 

familiar with systems programming under the MS-DOS 

SUMMARY OF THE APPLICATOR (of an operating system. For an extensive explanation of the inner 

Improved Process of Security as Hereinbefore workings of the MS-DOS operating system, reference is 

Described) 55 mac j e l0 standard texts in this field. For example, reference 

A preferred embodiment of the present inventions' is made to "PC Intern" by Michael Tischer, published in 

method (hereinbefore described as the "applicator") by 1994 by Abacus, 5370 52nd Street, S.E. Grand Rapids, 

which to apply an improved process of security (as herein- Mich. 49512. A second useful text . in this matter is "PC 

before described) will now be described with reference to Architecture and Assembly Language" by Barry Cauler, 

the accompanying drawings. 60 published 1993 by Carda Prints, 22 Regatta Drive, 

Referring now to FIG. 7, there is shown a standard format Edgewater, Wash. 6027, Australia, 

utilised for storing executables on disk, often occurring in The specific embodiment of the present invention will be 

the art, and in particular in conjunction with programs run on described with reference to altering an "EXE" executable 

the above mentioned operating systems. The standard program under DOS in accordance with the principles of the 

executable 16 normally comprises a header section 71, a 65 present invention. 

code section 72, and a data section 73. The header section 72 Referring now to FIG. 9, there is shown the structure 90 

normally stores a standard set of information required by the of an executable "EXE" program in M OS -DOS as normally 
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stored on disk. This structure is closely related to the 
structure 16 of FIG. 7 which illustrates the more general 
case. The structure 90 includes a header 71, otherwise 
known in MS-DOS terminology as the program segment 
prefix (PSP). This is normally followed by a relocation table 
91 which contains a list of pointers to variables within a code 
area 72 which must be updated with an offset address when 
the program is loaded into a particular area of memory. The 
operation of the relocation table is well known to those 
skilled in the art of systems programming. The next portion 
of structure 90 is the code area 72 which contains the 
machine instructions for operation on the x86 microproces- 
sor. This is followed by a program data area 73 which 
contains the data for code area 72. Finally, there may exist 
a number of overlays 92 which contain code which can be 
utilised in a known manner. 

Referring now to FIG. 8, there is shown the structure of 
EXE file header 71 in more detail. The table of FIG. 8 being 
reproduced from page 750 of the above mentioned Tischer 
reference. It should be noted that the header 71 includes a 
number of fields including, for example, a pointer 81 to the 
start of the code 72 (FIG. 7) and a pointer 82 to the relocation 
table 91 (FIG. 9). 

In the specific embodiment, the applicator program 60 
(FIG. 6) proceeds by means of the following steps: 

(1) The executable program 16 is opened for reading and 
a determination made of its size. 

(2) The header 71 (FIG. 9) of executable program 16 is 
then read in and a copy is stored within applicator program 
60. A copy of the header 71 is written out to form part 101 
of the new.exe file 30 as illustrated in FIG. 10. 

(3) Next, from the fields 81, 82 of the header 71 (FIG. 8) 
a determination is made of the size of relocation table 91 of 
executable program 16. 

(4) Next, determination is made of the size of the execut- 
able code 72 and data portions 73. 

(5) The relocation table 91 is then read into the memory 
of the applicator program 60. As noted previously, the 
relocation table 91 consists of a series of the pointers to 
positions within code segment 72 which are required to be 
updated when loading the program exe file into memory for 
execution. The relocation table is sorted 93 by address 
before being written out to the new.exe executable file at 
position 102. 

(6) As noted previously, the relocation table 91 consists of 
a series of pointers into code area 72. A determination is 
made of the size of a code, known as the "netsafe 1" code 
104, the contents of this code will be described hereinafter. 
Next, a search is conducted of the sorted relocation table 102 
to find an area between two consecutive pointers within code 
section 72 which is of greater magnitude than the size of 
netsafe 1 code 104. This area 94, designated part B in FIG. 
9 is located. If this code portioned 94 cannot be located the 
applicator program 60 exists with an error condition. 

Upon finding code portion 94, the code portion 95, also 
denoted part A is encrypted and copied across to form new 
code portion 103. Code portion 94 is then encrypted and 
copied to an area 105 of new.exe 30. The netsafe 1 code 104 
is then inserted by applicator 60. Code portion 96, also 
denoted part C is encrypted and copied across to form code 
portion 106. Data portion 73 and overlay portion 92 are 
copied into new.exe 30 as shown. A second portion of 
obfuscating code, denoted "netsafe 2" 107, the contents of 
which will be described hereinafter, is then inserted after 
overlays 92 and before code portion part B 105. 

(7) The header 101 is then updated to reflect the altered 
layout of new.exe executable 30. Additionally, the initial 
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address 109 of execution stored in header 101 is altered to 
be the start of netsafe 1 portion 104. 

(8) As mentioned before, code portions 103, 106 and 105 
are subject to encryption or encipherment in accordance 

5 with step 62 of FIG. 6. The encryption scheme utilised can 
be subjected to substantial variation. In this embodiment, the 
DES standard encryption scheme was utilised. This scheme 
relies on a fifty-six bit key for encryption and decryption and 
is well known in the art. 

10 Once encrypted, it is necessary to store the decryption key 
in new exe executable 30. A number of different methods 
can be utilised to store the key. The preferred method is to 
spread portions of the key to different positions within the 
executable 30. For example, bits of the key can be stored 

15 within the netsafe 1 code 104 and netsafe 2 code 107. 
Additionally, bits of the key can be stored within header 
portion 101. Also, it is envisaged that bits of the key can be 
stored in the condition codes which are a consequence of 
execution of various instructions within netsafe 1 area 104 

20 and netsafe 2 area 107 and/or the operating system 17 (FIG, 
5), with the overall requirement being that the key can be 
later extracted using a predetermined algorithm. 

(9) The next step is to patch the address of the start of code 
^ area 72 and netsafe 2 code area 107 into the required 

locations within netsafe 1 area 104. 

The netsafe 1 area is then written to the file containing 
new.exe executable 30. 

(10) The area 106 is then encrypted as aforementioned 
30 and written to the executable 30 followed by overlays 92 and 

encrypted netsafe 2 code portion 107. 

(11) As will become apparent hereinafter, upon execution 
of new.exe executable 30, netsafe 2, area 107 is responsible 
for loading code portion 105 over the top of netsafe 1 area 

35 104. Therefore, it is necessary to write the relevant addresses 
of the start and end of code portion 94 to the required 
position within netsafe 2 area 107. 

(12) As will be described hereinafter, netsafe 2 area .107 
is also responsible for decrypting the encrypted portions of 

40 codes 103, 104, 105, 106, and 107 and hence the netsafe 2 
area 107 must also store this combined code size for later use 
on decryption. 

Finally, a overall checksum for new.exe 30 is calculated 

45 and stored at the end of the file at position 108. This 
checksum is later used to verify the decryption procedures 1 
success and to prevent the execution of "scrambled" code, 
which would be the result if new.exe 30 were tampered with. 
As will be further described hereinafter, netsafe code 

50 areas 104 and 107 contain code to decrypt the encrypted 
areas of the new.exe 30, to repatch code portion 105 back to 
its original position, and to replace potentially insecure 
routines or easily spoofed screens normally utilised by the 
application (eg: unsafe keyboard drivers) with an alternative 

55 safe form of routine. 

Upon execution of the new.exe executable 30, the execut- 
able starts at the start of netsafe 1, area 104 (FIG. 11), as thus 
address has been previously patched into position 109 (FIG. 
10) of header 101 (FIG. 10). The netsafe 1 area 104 then 

60 performs the following steps (Al) to (A10). 

(Al) The first step is to disable all the interrupts apart 
from those necessary for continued operation of the com- 
puter device 18 (FIG. 1) (for example, memory refresh 
cannot be disabled). The disabling of interrupts includes the 

65 disabling of the keyboard interrupt in order to stop amateur 
"code snoopers" from determining the operation of the code 
area 104. 
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(A2) The next step is to interrogate the calling environ- read past the end of file of the disk copy of new.exe 30 (FIG. 

ment of the operating system stack to ensure that the 10) to ensure that no extension (eg: viral) has occurred, 

program new.exe was not called by a debugging program (B4) The encrypted portions of the memory copy (FIG. 

which is tracing the operation of new.exe. Additionally, the 11) of new.exe are then decrypted utilising the key and once 

data variables necessary for operation of netsafe 1 code area 5 decrypted, the decrypted portions are again checked and 

104 are defined to be on the operating system stack (Refer tested against predetermined data. 

Address OEH and 10H in FIG. 8). This stack will change The next step in execution of the netsafe 2 code 113, is to 

unexpectedly when in a code snooping or debugging envi- replace insecure (eg: keyboard) system routines with a more 

ronment and will cause the debugger to crash, thereby secure method. Referring now to FIG. 12, there is shown the 

stopping a it from following the operation , of new.exe 10 current slate of new.exe executable in memory. The 

executable 30 insertion of the more secure system routines then proceeds 

/aa\-tu • * ti a a *u i . % • . in accordance with the following steps (CI) to (C5): 

(A4) The interrupt trap addresses are then altered in a two /™\ c- n . « V • j ♦ 

, x ' ™_ r - \ , t c t - (CI) Firstly, a second memory allocation is done to set 

cnf o P nn Ce !f, f . f * ,J P , ^ a * area 51 (FIG. 13) for the storing of the secure 

SEG-OFF address format and occurs at this point with a hafdware romines ( keyDOard) . r * utines are then 

second stage occurring at a later tune as well be further ^ d ^ ^ ^ % ^ m {q ^ 

described herein below. By staging the alteration of interrupt memory area 51 

trap addresses, any code snooper will be further confused as (C2) Next> the ID Data entfy routines wh{ch are normally 

said trap addresses will initially be garbage. activated by the interrupt table 131 when dealing with 

(A5) Any input from the keyboard is further disabled by ID -Data input are altered such that, rather than pointing to 

informing the MS-DOS operating system to ignore any 20 corresponding areas of the MS DOS operating system 17, 

received keys. they point to the corresponding secure area 51. These 

(A6) The second stage of the revectoring of the normal interrupts include interrupt 9 which occurs when a key is 

debugging interrupts is then applied so that the normal P ressed °? » keyboard, interrupt 29h which read a key and 

debugging interrupts can be used by the decryption code, to „ interru P t 16/1 which les * for < he P resence of a ke ?" 

be described hereinafter, thereby making debugging almost 25 < C3 ) ^ executable 30 (FIG. 13) is then ready for 

impossible execution and the registers are initialised, the memory area 

" ' 113 deallocated & control passes to the original start address 

(A7) A check is then made to ensure that the above of executable program 16. 

processes have been successful in that the debugger inter- (C4) ft ^ be evident> that when executing) dl key board 

rupts do not point to any debuggers, the keyboard is still 30 calls (or other n> Data en try calls, if other than keyboard) 

disabled and the operating system has disabled the accep- will be passec i to keyboard (or other) routines 51 with the 

tance of keys from the keyboard. keyboard hardware being interrogated directly by keyboard 

(A8) The key for decryption is then reconstructed utilising routines 51 to return information to the calling program, 

the reverse process to that utilised in storing the information Keyboard routines 51 include a copy of the correct interrupt 

located in the key. 35 vector addresses for each keyboard routine and each time 

(A9) Turning now to FIG. 11, there is shown the standard the y arc , called ; a check 15 made °/ ^ e j nt *™P* ta ^ le l ° 
format of the executable new.exe 30 when executing in ensurc that u has ™ { ^ altered. Preferably, keyboard 
memory. As will be well known to those skilled in the art, ro ^ ines 51 P^tect the keyboard hardware by issuing con- 
an executing program under the MS-DOS system will troller reset or similar commands to flush the keyboard data 
include a stack 111 and work space 112. A memory alloca- 40 out of the circuitry after said data a retrieved to prevent 
tion (Malloc) call is then done to set aside an area 113 for the hardwarc eavesdropping or routines 51 utilise the protected 
loading in of the netsafe 2 code 107 of FIG. 10. The disk mechanisms of the central processor to protect said hard- 
copy of new.exe 30 (having the format shown in FIG. 10) is ware from eavesdropping. 

then opened by the netsafe 1 code 115 and an encrypted copy ( C5 ) When the executable 30 terminates, interrupt 21h (an 

of netsafe 2 code 107 (FIG. 10) is then loaded in from the 45 MS-DOS standard) is called. This interrupt is also revec- 

disk file, decrypted and stored in memory area 113. The tored to a corresponding area of routines 51. The termination 

relocatable pointers of the code contained within the netsafe code of keyboard routine area 51 restores the correct inter- 

2 code 113 are then updated to reflect the position of the ™V l posters in interrupt table 131 to point to the MS-DOS 

executable in memory. operating system 17, and clears the no-longer-needed pro- 

/a,^\^.i- iL i . a in 50 gram and data from memory before returning to the DOS 

(A10) Control is then passed to netsafe 2 code 113. & . , ir , . . 

v 7 r operating system by calling the real interrupt 21. 

The code area netsafe 2, 113 then performs the following t-u * a u 1 V u a- * r 

am Tray foregoing describes only on particular embodiment of 

steps ( ) to ( ). t j ie p resent invention particularly to the operation of the 

(Bl) The portion of code of the disk copy denoted part B, MS-DOS operations system. It will be evident to those 

105 (FIG. 10) is read in from disk in an encrypted format and 55 skilled in the ^ thal the pr i ncip i es outlined in the particular 
written over the old netsafe 1 code 115. embodiment can be equally applied to other operating 

(B2) As will be further described hereinafter, the netsafe systems in accordance with the objects of the present 

2 area 113 includes a number of keyboard routines which are invention. Further, combinations, variations and/or 

preferably stored in an encrypted format. Therefore, the next modifications, obvious to those skilled in the art, can be 

step is to apply the decryption to any of the encrypted areas 60 made to the present invention. All such combinations, varia- 

of netsafe 2 code area 113. After decryption, the netsafe 2 tions and/or modifications should be considered to fall 

area 113 is checksummed and the result is tested against a within the scope of the invention as broadly hereinbefore 

prestored checksum to ensure the integrity of netsafe 2 area described and as hereinafter claimed. 

113- I claim: 

(B3) The disk copy of the new.exe is then again read in 65 1. A computer system having software having input 

and checked against prestored check data to ensure that it routines with enhanced security features for entry of 

has not been changed. Additionally, an attempt is made to ID -Data comprising: 
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a processor; and 

a memory, wherein said software stored in said memory 
when executed by said processor comprises: 
anti-spy techniques within said input routines which 

prevent or hamper eavesdropping; 
detect tampering of said software which, upon detec- 
tion of tampering, either disallow the subsequent 
entry of ID-Data into said input routines, or which 
invalidate said ID-Data in order to disallow current 
and subsequent access to that which said ID- Data 
would have otherwise allowed; and 
further comprising at least one of the following code 
contained in said software: 

code to automatically scan memory of said software 
one or more times before or during execution of 
said software to detect tampering; 

code to store or communicate details of detected 
tampering for later examination, said details 
including all or part of said tampered software, or 
other information available to said tampered soft- 
ware from said computer system; and 

code to prevent, or detect and subsequently prevent 
tracing, or misleading code debuggers and the 
execution of tracing by utilizing debugger trap 
facilities for the normal operation of said security- 
enhanced software, or monitoring system timers 
or timing-sensitive instructions or monitoring 
CPU stack contents or monitoring system buffers 
to detect the activity of code debuggers, or dis- 
abling facilities such as, the keyboard, serial ports, 
printer ports, mouse, screen or system interrupts in 
order to hamper code debuggers, or testing that the 
disabled status is still true of said facilities to 
detect code debuggers, or utilizing system inter- 
rupts which would ordinarily be used by code 
debuggers for the custom purposes of said 
security-enhanced software, or utilizing CPU 
instruction caches together with self-modifying 
code to mislead code debuggers, or scanning or 
interrogating the operating system or executable- 
load-process to detect code debugger instructions 
or environments, characterized in that the program 
optionally includes a process or multiple pro- 
cesses which are resident or child processes of 
said security-enhanced software which execute 
during system interrupts of after the parent process 
has terminated in order to hamper tracing. 

2. A method of altering an original executable program to 
form an altered executable program having increased 
security, said method comprising the steps of: 

(a) inserting obfuscating code into a first number of 
predetermined areas of said executable program; and, 

(b) encrypting portions of said executable program for 
later decryption upon execution; such that, upon execu- 
tion of said altered executable program, said execution 
includes the steps of; 

(c) decrypting the altered executable program; and 

(d) restoring said altered executable program to said 
original executable program. 

3. A method as claimed in claim 2 further comprising one 
or more of the following: 

said obfuscating code include replacement codes for 
insecure system routines and said method further 
includes the step of (e) replacing the execution of said 
insecure system routines with said replacement codes; 

said steps (c) and (d) occur while simultaneously sub- 
stantially disabling eavesdropping on the operation of 
said steps (c) and (d) by any rogue program; 
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said step (a) includes inserting a portion of said obfus- 
cating code into the. code area of said original execut- 
able program; and, 

said step (e) includes altering portions of an interrupt 
vector table to point to said replacement codes; 

said step (b) includes the storing of a decryption key in a 
plurality of predetermined areas of said altered execut- 
able program, said predetermined areas include the 
condition codes of predetermined instructions of said 
altered executable program. 

4. A method of providing for a secure entry of ID data or 
input information in a computer system comprising: 

a. activating a visual display or animation or audio 
feedback (hereinafter called an audiovisual component) 
as part of said secure entry of said ID data or said input 
information so as to substantially hamper cumulation of 
a secure entry process; and 

b. audio/visual component feedback comprising at least 
two of: 

i) at least part of said input information; 

ii) at least part of information based upon some trans- 
formation of at least part of the software comprising 
said audio or visual component or the computer 
operating system upon which said audio or visual 
component operates. 

5. A method as claimed in claim 4 wherein 

said audiovisual component has repeatable characteristics 
during subsequent invocations of said entry process, 
such that said audiovisual component on each invoca- 
tion of said entry process has a predetermined resem- 
blance to the audiovisual component of all other invo- 
cations of said entry process, or, 

said audiovisual component is varied in accordance with 
the information entered. 

6. A method as claimed in claim 4 wherein said audiovi- 
sual component comprises moving parts and/or includes 
2,5 -dimensional animation or 3-dimensional animation, and/ 
or, said audiovisual component includes a representation of 
said input information, preferably comprising (a) display of 
a single graphical object, and/or (b) production of a single 
audio -feedback sequence, after the entry of all or part of said 
input information. 

7. A method as claimed in claim 6 wherein said input 
information representation includes animation of input char- 
acters and/or audible or other feedback determined by input 
characters, wherein the representation of said input charac- 
ters may optionally vary for each character based on the 
result of a predetermined transformation of the preceding 
inputted characters, wherein said transformation utilises 
cryptographic or hashing methods. 

8. A method as claimed in claim 6 wherein: the ease by 
which faithful replication of said audiovisual component is 
substantially reduced by inclusion in said audiovisual com- 
ponent the techniques of on screen shadow rendering and/or 
spot or flood scene fighting effects and/or scene or object 
shading and/or transparent or translucent objects and/or 
shiny, reflective, or mirrored objects and/or real-time ani- 
mation roughly obeying real world gravitational effects 
and/or single-image-random-dot stereogram bitmaps or 
backdrops and/or partial scene masking effects and/or full or 
partial scene distortion or diffraction effects and/or animated 
objects designed to resist simple hidden-surface removal 
techniques and/or animated bitmaps and/or audible echo 
effects and/or differing audio voice effects and/or differing 
audio volume and/or differing audio tones or pitches; 
wherein, said audiovisual component is optionally immedi- 
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ately recognisable to human beings and includes information 
which identifies to the user the application to which said 
audiovisual component belongs; wherein, the ease by which 
faithful replication of said audiovisual component may 
optionally be further reduced by inclusion in said audiovi- 5 
sual components animation object movement timing such 
that at near regular and frequent intervals regularities occur 
which are obviously recognisable to users of said entry 
process; and preferably, wherein, said entry process includ- 
ing said audiovisual component utilises a substantial portion 1Q 
of the computational resources of said computer system; 
and, wherein, said entry process code responsible for said 
audiovisual component is coded in the assembly language of 
the computer system preferably wherein recording said 
audiovisual component by said computer system is disabled. 

9. A method as claimed in claim 4 wherein (a) the facility 15 
to- suspend or swap-out said entry process is either disabled, 
or, (b) immediately upon suspension request, said entry 
process is protected against subsequent examination by 
encryption or by termination and removal from memory or 
said entry process, or, (c) where the facility to allow the 20 
central processor or processors of said computer system to 
execute code other than the code of, or the code necessary 
for said entry process is either disabled or else said entry 
process is protected against examination. 

10. A method as claimed in claim 4 wherein: said entry 25 
process hampers simple recording by utilising the maximum 
practicable use of audiovisual framerate, and/or audiovisual 
resolution, and/or screen colours; and/or, audiovisual design 

in said audiovisual component on said computer system, 
and/or said entry process hampers the compression of 30 
recorded output from said audiovisual component by utilis- 
ing high audiovisual entropy and/or by the inclusion of 
random or other noise in said audiovisual component; 
wherein, said audiovisual component preferably includes, 
continuous output such that the looping of only a subset of 35 
said output shall not reproduce a copy largely indistinguish- 
able to said audiovisual component. 

11. A method as claimed in claim 4 wherein said ID-Data 
or said input information is encrypted by a cryptographic 
process or hashed immediately upon entry and a plain text 40 
equivalent is not stored by said computer system; and/or, 
wherein disablement of one or more interrupt instructions 
(or equivalent CPU devices) is utilised to protect said 
cryptographic or said hash process of said ID-Data to 
hamper the recovery of said ID-Data by processes other than 45 
said entry process. 

12. A method as claimed in claim 4 wherein said input 
routines or said secure entry process prevents the 
re-vectoring of system interrupts in order to protect said 
ID-Data or said input information form being stolen, by 50 
means of re- applying interrupt vector pointers one or more 
times and/or by means of examining interrupt assignments 

in order to perform a predetermine d function should the 
expected assignments be altered. 

13. A method as claimed in claim 4 wherein in order to 55 
further authenticate and/or identify said user, additional 
aspects of said ID-Data or said input information are used 
including the duration of individual key presses and/or 
mouse button presses and/or the delay between subsequent 
individual key presses or mouse button presses and/or the 60 
user's selection of particular keys when more than one 
equivalent exists and/or the acceleration or velocity charac- 
teristics of mouse usage and/or where said input information 
includes information from other sources including biometric 
and/or smartcard information. 65 

14. A method as claimed in claim 4 wherein said input 
routines or said secure entry process authenticates itself 



using (a) executable code checksums of RAM or other 
images of its own executable code and/or data, (b) and/or 
comparison of memory with other stored copies of said 
executable code, (c) and/or decryption of said entry process 
(d) and/or detection of executable tampering by examination 
of the executable's environment (e) and/or comparison of 
executable size with expected values (f) and/or by attempt- 
ing to read past the end of the executable file to determine 
that the size is correct; parts (a) through (f) occurring either 
upon initial load or during or after execution one or more 
times or continually during execution. 

15. A method as claimed in claim 4 wherein said input 
routines or said secure entry process: 

makes use of system interrupts to monitor itself in order 
to detect alternation of itself; 

incorporates means by which to notify and/or transmit 
authentication failure details to a third person or pro- 
cess should said self authentication fail, records a log of 
the usage and/or details of the user of said input 
routines or said secure entry process; 

incorporates warning s within the executable image indi- 
cating that examination and/or tampering is prohibited; 

stores loading and/or decryption routines are stored within 
the executable image in such a way as they initially 
replace other entry process routines and upon success- 
ful decryption and/or authentication, said other entry 
process routines are replaced; 

hampers executable -code tracing through control- flow 
changes in debug environments or through disabling 
one or more system interrupts and/or disabling the 
keyboard and/or disabling the mouse or other input 
devices and/or making use of the program stack pointer 
to discern existence of a debug environment and/or 
utilising debug interrupts for program code operation 
and/or self-modification of executable code and/or 
examination of CPU flag registers and/or verification of 
disabled interrupts still-disabled state and/or verifica- 
tion of disabled keyboards still-disabled state and/or 
loading additional executable code into memory during 
execution; 

includes obfuscating assembly language dummy opera- 
tion codes or instruction prefixes inserted after one or 
more unconditional branches to hamper executable 
disassembly and/or decompilation and/or reverse engi- 
neering; 

becomes securely activated by its activation process and/ 
or a host or server computer using a challenge/response 
activation protocol or using public or private key 
cryptographic methods; and/or 

becomes stored outside of said computer system memory 
in encrypted form and/or where said entry process 
employs techniques to hinder executable-code tracing 
and/or executable -code disassembly or disclosure or 
decompilation and/or executable -code tampering and/ 
or executable-code hot-patching and/or reverse- 
engineering and/or pre, in, or post-execution 
executable -code recording, copying, eavesdropping or 
retrieval and/or theft of said input information from 
keyboard hardware or software or drivers. 

16. A method as claimed in claim 4 wherein said audio- 
visual component contains watermark information incorpo- 
rated into the scene to allow close inspection of said audio- 
visual component to distinguish between the genuine 
process and a close replica. 

17. A computer program product for requiring the entry of 
ID-data for access thereto, said program characterized by 
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having an enhanced security structure or features to prevent 
fD-data eavesdropping or theft or to ensure authenticity, 
having: 

a computer readable storage medium for holding codes; 
and 

further comprising one or more of the following: 
code for preventing ID-data eavesdropping, by commu- 
nicating directly with input hardware of a computer; 
code for preventing disassembly thereof, said code for 
preventing disassembly comprising obfuscating inserts, 
dummy instructions or executable encryption; 
code for preventing tampering therewith, said code to 
prevent tampering comprising: 
code for reading its own image including external or 
internal memory images or calculating check data 
associated therewith; and 
code for comparing said read image or calculated 
check-data with an authentic image or check-data to 
prevent execution-tracing, and code for disabling 
interrupts or for performing timing-sensitive instruc- 
tions between interrupts; or, 
code for ensuring authenticity, by providing an audio or 
video feedback to an output device to be viewed or 
heard by an operator. 
18. A method for enhancing the security of access to user 
identification data by software on a computer system com- 
prising: 
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using an obfuscating process to hamper or prevent eaves- 
dropping; 

detecting tampering; and 

5 if tampering is detected, selecting an action of either 
disallowing subsequent entry of the user identification 
data into input routines or invalidating the user identi- 
fication data in order to disallow current and subse- 
quent access to the user identification data. 

19. The method of claim 18, wherein program code that 
is vulnerable to eavesdropping is replaced with equivalent 
program code wherein said vulnerability is removed, and 
wherein said equivalent program code communicates 

15 directly with the hardware of the computer while disabling 
functions that would permit rogue software to eavesdrop. 

20. The method of claim 18, further comprising using 
encrypting or inserting dummy instructions in said user 

20 identification data to hamper or prevent eavesdropping. 

21. The method of claim 18, wherein detecting tampering 
includes code that re-reads the code's own external-image or 
the code's internal memory image and compares a calcu- 
lated checksum of said image with a pre -calculated check- 

25 sum. 

***** 
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